![]() |
![]() |
![]() |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
![]() |
![]() |
To access the contents, click the chapter and section titles.
Oracle Performance Tuning and Optimization
Redo Log Buffer Latch ContentionThe access to the redo log buffer is controlled by two types of latches: the redo allocation latch and redo copy latches. The redo allocation latch controls the writing of redo entries to the redo log buffer. To write an entry into the redo log buffer, the user process must obtain the redo allocation latch, allocate space in the redo log buffer, and then copy the entry into the buffer. Whenever the user process has finished copying into the redo log buffer, it releases the latch, thus allowing other user processes to use the redo allocation latch. Because only one redo allocation latch exists, only one user process can write to the log buffer at a time. The maximum amount of data that can be written into the latch is specified by the initialization parameter LOG_SMALL_ENTRY_MAX_SIZE. If the redo entry exceeds the value specified by LOG_SMALL_ENTRY_SIZE, the user process must obtain a redo copy latch before copying into the redo log buffer. After allocating a redo copy latch, the user process can write into the buffer. With multiple-CPU machines, you can have multiple redo copy latches. That is, you can allow simultaneous entries into the redo log buffer, which increases performance. The number of redo copy latches is determined at instance startup by the parameter LOG_SIMULTANEOUS_COPIES; the value defaults to CPU_COUNT. In a single-CPU machine, there are no redo copy latches and all access to the redo log buffer is through the redo allocation latch, regardless of size. There are two ways of accessing both the redo allocation latch and the redo copy latches:
Determining Latch Contention Problems Latch contention can be determined by examining the dynamic performance table, V$LATCH. The significant values are given here:
You can look for contention on latches by using the following SQL statement: SQL> SELECT SUBSTR(name,1,20), gets, misses, sleeps, immediate_gets, immediate_misses 2 FROM v$latch 3 WHERE name IN ('redo allocation', 'redo copy'); SUBSTR(NAME,1,20) GETS MISSES SLEEPS IMMEDIATE_GETS IMMEDIATE_MISSES -------------------- -------- -------- -------- -------------- -------------- redo allocation 2744 0 0 0 0 redo copy 0 0 0 0 0 If the ratio of MISSES to GETS exceeds 1 percent or the ratio of IMMEDIATE_MISSES to the sum of IMMEDIATE_MISSES and IMMEDIATE_GETS exceeds 1 percent, contention is probably affecting performance in your system. Solving Latch Contention Problems If latch contention is causing performance problems, there are several things you can do to try to reduce this contention. To reduce contention on the redo allocation latch, you can reduce the size of LOG_SMALL_ENTRY_MAX_SIZE to minimize the time any user process holds the latch. This is done by reducing both the size and number of redo entries copied onto the redo allocation latch. Resetting the value of LOG_SIMULTANEOUS_COPIES can reduce contention by adding more redo copy latches. You may see improvement by adding up to twice the number of redo copy latches as CPUs. Another way to reduce the time a user process holds the latch is by requiring the user process to prebuild the redo entries before it obtains the latch. This prebuilt entry reduces contention on the latch by not using CPU time to build the entry while the latch is being held. By setting the initialization parameter LOG_ENTRY_PREBUILD_THRESHOLD, any redo entry of a smaller size than this parameter must be prebuilt. The default for LOG_ENTRY_PREBUILD_THRESHOLD is 0 (that is, it requires no prebuilding). Although redo log buffer latches are usually not a problem, they can be a source of contention under certain circumstances. You have seen how to check for latch contention and how to reduce contention if you find it. Unless you are under extremely heavy loads, it is not necessary to monitor the redo buffer latches.
|
![]() |
Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. |